Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/93mar/sdr-minutes-93mar.txt

Text File | 1993-04-29 | 18.5 KB | 379 lines

Editor's note:  Minutes received 4/15/93.  These minutes have not been edited
                and the attendee list has not been appended.

SDRP WG IETF
Wed 3/31

Meeting Minutes prepared by Deborah Estrin and Tony Li.

Changes to the specification were presented and discussed.  Major
modifications were made to support interior SDRP.  The new packet header
format was presented.  All packets now carry a hop count, which formerly
was only in data packets.  All packets now carry target router and
notification fields, even though only control packets use them.
Notification uses a byte which would be necessary for alignment anyhow, so
this causes four bytes of overhead on data packets.  The source route
length is now the number of IP addresses, not the number of bytes.  The
next hop pointer also now is in terms of addresses.  The source route now
supports interior routing due to the need expressed at the previous SDRP
BOG for source demand routing within domains.

Source routes now contain three types of entries, all of which are
syntactically IP addresses.  An entry may be a normal IP address, or an AS
number, or a change in source route attributes.  An AS number is encoded in
the low order two octets of network 128.0.0.0.  Changed source route
attributes are encoded in the low order three octets of 127.0.0.0.
Currently, the only change possible is to change the strict/loose source
route bit.  This accommodates source routes which need a mix of strict and
loose source routing.

There are changes to forwarding to match the new source route format.  If
the address in the source route that is currently being processed is a
normal IP addr, then forwarding checks to see if it matches the local
address and if so, looks at the next address in the source route.
Otherwise the packet is forwarded to the indicated address using normal IP
forwarding.  If the address in the source route encodes an AS number that
matches the local AS#, then forwarding looks at the next entry in the
source route; otherwise the packet is forwarded to the indicated AS looking
at D-FIB If the address in the source route encodes a change in attribute
type, then the SDRP speaker reaches in and sets the attribute bit
accordingly and looks at the next source route entry for processing.

A brief SDRP overview was presented for new folks; see the BOF minutes from
the previous IETF or the Unified architecture document for background.

We discussed a draft of the SDRP usage document distributed before IETF.

SDRP can be used in the near term to provide special routes that complement
existing IGP and BGP/IDRP routing.  We can phase SDRP into the operational
Internet without wholesale replacement of routing.

At the same time as we are proceeding with protocol specifications for
nearer term experimentation, longer-term issues are already under
consideration. To provide a sense of "where we are headed" with this
protocol and the Unified architecture in general, a companion document on
SDRP futures has also been drafted.

In the packet format and forwarding protocol specification we do not
specify how an SDRP router that originates an SDRP packet acquires an SDRP
route.

An SDRP route is defined as a sequence of domain identifiers and/or IP
addresses, or a combination; the route may be strict or loose.

The usage document should discuss mechanisms for acquiring SDRP routes
using EXISTING routing information distribution mechanisms (BGP/IDRP).  In
particular, it will cover the following three sources of routes: BGP/IDRP
routes, manually configured routes, and route fragments

Any legal BGP or IDRP route is, by definition, a legal SDRP route, so long
as there are SDRP speakers at appropriate points along the path.

Every BGP/IDRP speaker may maintain information about multiple feasible
routes to a destination (routes advertised by different neighbors).  But a
BGP speaker chooses at most one route to be active (selected), and an IDRP
speaker may choose more than one route to be active (selected) only if all
selected routes have different ``distinguishing attributes''.  As a result,
the currently active (selected) IDRP/BGP route may not be appropriate for
the packet.

One of the simplest forms of SDRP route acquisition is to select among the
alternative routes advertised by the node's neighbors.  This requires NO
modifications to BGP/IDRP.

It does require development of appropriate route selection rules, both
manual and semi-automated, for selecting particular BGP/IDRP routes to be
used as SDRP routes.

Network administrators can also create SDRP routes by examination of
network topology BGP/IDRP databases, or manually collecting network
information through active probing (traceroute).

The operational status of routes can be determined dynamically using the
passive and active mechanisms defined in SDRP packet forwarding, allowing
the scheme to adapt to topological changes.

For the usage document we need to give examples of useful manual
configurations. We must also emphasize need to use PROBE to detect black
hole routes and the utility of having several SDRP routes as fallback
routes to somewhat make up for the fact that these will be "static" due to
manual configuration.

Route fragments from different BGP/IDRP routes can be used, in part or
whole, to create desired SDRP routes that do not appear in the node's
neighbors' BGP/IDRP tables.  This allows the administrator to "cut and
paste" to create new routes.

If SDRP is used within a domain, an IGP route can be used as an SDRP
routes.

Additional information derived from IGP can also be used to construct
routes, e.g., the OSPF link state database for reachability within the OSPF
system.

Interior SDRP is an area that in particular needs further discussion and
development of a usage model. For example, we need to a) clarify how you
get information about exit points into the interior, b) investigate the use
of information that OSPF and ISIS carry already, and c) consider adding the
ability to query BGP speakers internally.

Another mechanism not given in the specification is how a source host's
SDRP-speaking border router maps a particular packet to a particular SDRP
route.  This is not part of the protocol specification because it can be
left to local control; we need not be coordinated across the internet, or
even across the set of routers on a single path.

However, to use SDRP, the network administrator must be able to configure
the information used to map host-generated payload packets to appropriate
routes, therefore it must be addressed in the usage document. The mapping
indicates whether a packet can be sent out using the BGP/IDRP route; and if
not, which available SDRP route can be used (if any).

A domain may choose any mapping function that is unambiguous and whose
input information can be found in the payload packet or locally to the
router (e.g., based upon incoming interface); but may "pay for" more
sophisticated mappings.

For the usage document we need to develop good examples, clarify where the
mapping/classification is done and tradeoffs between doing it closer to
host and at border router.

BGP/IDRP and SDRP routes have transit policy qualifications associated with
them.  The syntax and semantics of SDRP policies should be consistent with
transit IDRP/BGP policies.  We should probably proceed by initially using
the existing BGP/IDRP policy semantics and syntax and evaluating the need
for extensions after gaining some experience.

For the next IETF we will review the IDRP policy language and identify if
there are unmet needs for SDRP

In the current specification, we disclaim any attempt to provide
secure/verifiable enforcement of transit policies. The essential tools
needed for this security service are more a function of the authentication
and integrity mechanisms available in the protocol providing delivery
service for SDRP, than of SDRP itself.

However, transit policy conformance can be audited by sampling data to
identify violators. Spot checks can be effective andare used in many other
kinds of systems (computerized and manual).  Auditing procedures and
sampling rules are a subject for local control and may vary across
different SDRP routes.

It would be useful to develop some examples for the usage document.

The only planned modification of BGP/IDRP is an optional attribute
indicating that a particular domain supports SDRP and optionally specifies
address(es) of SDRP speaker(s) in the domain.  This is important for route
selection and forwarding decisions.

There are two proposals for this function so far and the arguments for and
against will be discussed shortly on the SDRP mailing list.

SDRP supports interior policy routing by allowing SDRP routes to carry IP
addresses.  This can be used to direct traffic via configured paths in the
source domain.  It can also be used to direct routing of packets within
other domains; for example, by specifying a particular exit router for a
transit domain.  Particular routes within the destination domain can also
be specified; but this requires detailed knowledge of the topology and
addressing of other domains which requires mutual agreements for
information update between domain administrators.

In the usage document we should discuss the possible use of OSPF and ISIS
information and the implications for attempting to use this (or not) with
other interior routing protocols such as RIP, or IGRP.  We should also
document the use of IBGP for this purpose.

The Unified architecture is designed to allow evolution.  SDR was also
designed to allow innovation without global coordination.  We are working
to specify parts of the protocol that could be implemented and used in the
short term such that they will interwork with other parts of the
architecture still under development.  In particular, we have so far
specified the packet format and forwarding protocol while details of SDR
route computation are still under development.

Mechanisms for route computation and even information
distribution/collection can be changed more readily than packet forwarding
mechanisms because route computation is a local matter.  Information
distribution concerns some subset of routers or domains whereas packet
forwarding procedure must be agreed upon by all routers that implement
SDRP.

Important but evolving aspects of the architecture include: route
construction, policy language, route setup, multicast routing, and
alternate path routing for reservation-oriented (virtual circuit) traffic.

We want to extend route construction mechanism to obtain routes that
conform to source-specific policies where route's use is restricted to
certain sources, or QoS requirements where a route supports a particular
performance or policy related QoS (color), and/or path-constraint policies
where a route must pass through or avoid particular transit domain(s)).

Routes available via IDRP are the result of path selection processes in all
the intermediate IDRP speakers between the source and destination.  So we
need mechanisms for source to obtain information about other routes that it
the source is allowed to use but that intermediate domains filtered out as
a result of their path preferences.

We can characterize different approaches to route construction according to
whether construction is based on distributed or centralized processing.
For example: using an IDRP route is a form of distributed processing since
route is constructed hop by hop by nodes on a path.  Collecting
inter-domain topology/policy information from around the network and
computing a route at the source is a form of centralized processing.  Route
fragments represent intermediate point where the source centrally controls
the acquisition and concatenation of fragments, but the fragments
themselves represent the result of a distributed computation.

Query is one example mechanism where a source domain SDRP speaker queries
its immediate neighbor IDRP domains to get all available routes to a
particular destination (possibly with QOS specified as well).

The SDRP speaker could also query non-neighbor IDRP speakers; but this raises
the question of heuristics for deciding whom to query... which is
still a subject for further research.

Query is an example of centralized processing and can also be used to
obtain route fragments.

The Extract mechanism is a second proposed mechanism for on-demand SDRP
route acquisition.

For example, the source could send an extract request to the destination
indicating desired QOS and possibly exclusionary transit information (e.g.,
what transit it does NOT want to use) The destination would then cause IDRP
to propagate back routes that fit the characteristics specified by the
source. The routes would NOT be stored in the RIBs en route back to the
source; rather the information would be passed along on an FYI basis.

Extract is an example of distributed processing and could also be extended
to send extract request to a preferred transit domain for it to initiate
the extract Extract could also be used to obtain route fragments.

The big question is how to constrain the propagation of the return
information; hop-count limits, limits on the number of routes propagated by
each domain are possibilities, each of which trades off overhead for some
loss of information

Other schemes for collecting information and computing routes are the
subject of ongoing research.  However, the combination of extract, query,
and route fragment mechanisms may be adequate to meet most needs; this
needs further study.

We need a common language for specifying policy constraints on all routes.
This would allow other domains to do policy computations to determine
feasible routes.  The language must be extensible.

For example, in response to a policy query, a domain may respond with its
policy configuration.  The Policy language would look like a boolean
expression; and policy computation would consist of evaluating this
expression.  Syntactically, the expression appears as a series of terms;
satisfying any term satisfies the expression.  Possible variables include:
QOS of the packet, source domain, source address, destination domain,
destination address, transport protocol, application protocol, time of day,
and inter-domain path in use.  Terms that contain unrecognized variables
would be ignored.

The initial specification for packet format and forwarding includes a full
SDRP route in every packet sent.

When the duration of a packet stream is significantly longer than the end
to end delay, and if the payload in the packets is small it is worth
establishing state information in SDRP speakers along route, instead of
carrying full a SDRP route in every packet, i.e., "setup".  Once state is
established the source can rely on a route identifier in each packet and
thereby reduce SDRP packet header size and processing time.

However in designing a setup protocol it is important to not IMPOSE setup
on all SDRP speakers (might be short on state space or might not otherwise
wish to support setup).

A strawman proposal for setup operations was presented.

SDRP multicast would coexist and interoperate with IDRP/BGP multicast
routing mechanisms.  We anticipate more than the single IP multicast
routing model currently used in the internet.  IDRP may be used for setting
up the multicast distribution trees (or branches thereof) when the generic
routes satisfy the requirements of the application and group (i.e., QOS).

In particular there will be complementary mechanisms that are more
efficient than DVMPR or MOSPF style multicast for supporting sparse
multicast groups. Both IDRP and SDRP will be used to support these
mechanisms.

SDRP would set up multicast distribution trees (or branches thereof)
when the generic routes do not meet the needs of the application and
group.

SDRP can be used to support alternate path routing for reservation (or more
generally virtual circuit) traffic.  Source routing is good for achieving
alternate path routing because it has inherent loop avoidance and it avoids
placing burden on intermediate switches to compute and retain multiple
routes to each destination.

Alternate path routing is particularly important for reservation traffic
where a call setup request may be rejected due to insufficient resources at
some intermediate switch/link as a result of heavy utilization.  In this
case source would like to attempt alternate routes that do not go through
the bottleneck link.  SDRP can provide a source with alternate, loop free,
routes; particularly appropriate when SDRP setup is used.

A recent Internet Draft by Coltun and Sosa also concluded that source
routing is the best means of achieving alternate path routing for virtual
circuit routing.

Given that a route must have sufficient resources to accommodate a
reservation flow (i.e., stream, call), it might be useful for the source to
maintain recently measured load levels on those links in the network that
it uses frequently; for example from those links used by active flows.
There are open research issues to resolve in the inter-domain case where
detailed information of remote domains not available.

Because SDRP can be used to support interior routing, SDRP could be used
for alternate path routing within areas of a domain and within domains.

Initially it may be simplest to have the source try to use an alternate
domain level route when a reject is received from a remote domain; this may
be justified if one assumes that the hop by hop routing choice used in that
domain to traverse the domain does reflect long term utilization in that
domain.

There is much more to be said on all of these subjects.

Projects and milestones were discussed.  The following is a list of topics
to be discussed and people interested in working on them.

1. Usage Document
(Draft before July IETF)
(Deborah Estrin, Yakov Rekhter, Peter Ford)

2. BGP/IDRP Attributes Draft
(Draft by May)
(Tony Li, Yakov Rekhter, Deborah Estrin (referee))

3. Prototype
(Working prototype for others to see by June)
(Daniel Zappala, Tony Li (will look it over))

4. Setup spec
(Draft before July IETF)
(Deborah Estrin, Tony Li, Osmund deSouza)

5. Information Distribution and Route Selection
(Draft description of Extract Mechanism (not spec) and more detailed plan
for how to proceed in short and mid term by July IETF)
(Tony Li, Steve Hotz, David Bridgam [e-mail], Yakov Rekhter,
Brijesh Kumar)

6. Policy Language
(Presentation and discussion at July IETF; draft document for November)
(Tony Li, David Karrenberg, [e-mail], Steve Hotz, Sue Hares,
Steve Willis)

7. Multicasting
(Possible draft for November)
(Deborah Estrin, Osmund deSouza [e-mail])

8. Use of SDRP for adaptive Routing
(Discuss at July or November IETF;  In the mean time discuss with vcroute BOF)
(Deborah Estrin, Daniel Zappala)